Specialized computer programs called browsers are now widely used in networked computer systems for the purpose of retrieving and interacting with information stored in servers. A browser is a computer program specifically designed to help users view and navigate hypertext, on-line documentation, or a database. The term “browser” most often refers to a computer program designed to permit a user to view and interact with hypertext information, such as pages and programs written in the Hypertext Markup Language (HTML) that is communicated using the Hypertext Transfer Protocol (HTTP).
FIG. 1 is a block diagram showing a client-server system, in which client 100 communicates over a network 104 with server 106. Client 100 executes a browser 102. Server 106 executes application 108, which has access to one or more stored electronic documents 110.
In this configuration, browser 102 may establish a connection through network 104 to application 108. For example, browser 102 opens an HTTP connection through network 104 to an HTTP server running on server 106, or an HTTP daemon of application 108. Under control of client 100, browser 102 issues a request that specifies one or more of the documents 110 using a document identifier, such as a Universal Resource Locator (URL). Server 106 receives the request, parses it, retrieves the specified document from among documents 110, and sends a copy of the document in a response to browser 102. Browser 102 receives the document, parses coded instructions within the document, e.g., HTML source code, and displays the contents of the document at client 100 according to the coded instructions contained in the document.
Browsers can be configured as stand-alone computer programs or as processes that can be called from within another application program. Examples of stand-alone browsers are NCSA Mosaic, Netscape Communicator®, and Microsoft Internet Explorer®. Netscape Communicator and Microsoft Internet Explorer also are available in the form of executables that can be called from within an application program.
Browsers also have numerous graphical user interface display capabilities, communications functions, and security functions. For example, the HTML 3.0 standard defines various graphical user interface elements (“widgets”) that a browser can automatically create and display when an HTML source document contains a particular type of command. However, there is presently no way for a separate application program, at the client or at a separate server, to selectively invoke such capabilities and functions without sending an HTML document to the browser for standard processing. There is a need for a mechanism whereby an application can invoke a particular function of the browser, and the browser can obtain data values from the application that are needed for proper or successful execution of the function that is invoked.
In conventional approaches, a browser is invoked from within an application program in order to load a page based on a standard protocol such as HTTP, file transfer protocol (FTP), etc. In the current approach, the application can pass output to the browser only by creating and passing a URL to the browser that defines a particular static page on a particular server, or a script and parameters for use by the script. An HTTP server or an application that is addressed by the browser then generates an output page and instructs the browser to load it. However, this approach has many disadvantages and drawbacks.
For example, HTTP and FTP are cumbersome to use for certain kinds of interactions between an application and a browser. CGI scripts or other mechanisms have to be used in order to request application functions and pass variable values or references using HTTP. The lists of parameters and values that appear in the scripts are complicated and must be carefully constructed and concatenated to assure proper operation.
The HTTP approaches require, to at least some extent, the HTTP protocol to carry out functions for which it was not designed. The scripts and other parameter passing mechanisms are grafted onto HTTP and are functional, but they are not elegant and have definite limitations. There is a need for a new protocol or an improved protocol that is intended for and designed from the ground up to handle communications between a browser and an application or server.
Moreover, using the traditional protocols, the browser cannot easily obtain information that it may need from the application while the application is running. There is no convenient way to obtain, for example, the value of a single variable that is maintained by a Web application.
Based on the foregoing, there is a clear need in this field for a mechanism that enables a browser to directly access functions and data that are maintained by an application executed remotely or separately from the browser.
Other needs and objects will become apparent from the following description.